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Abstract 

Bidirectional typechecking, in which terms either synthesize a type 
or are checked against a known type, has become popular for its 
scalability, its error reporting, and its ease of implementation. Fol¬ 
lowing principles from proof theory, bidirectional typing can be ap¬ 
plied to many type constructs. The principles underlying a bidirec¬ 
tional approach to indexed types ( generalized algebraic datatypes ) 
are less clear. Building on proof-theoretic treatments of equality, 
we give a declarative specification of typing based on focaliza- 
tion. This approach permits declarative rules for coverage of pat¬ 
tern matching, as well as support for first-class existential types 
using a focalized subtyping judgment. We use refinement types to 
avoid explicitly passing equality proofs in our term syntax, making 
our calculus close to languages such as Haskell and OCaml. An 
explicit rule deduces when a type is principal, leading to reliable 
substitution principles for a rich type system with significant type 
inference. 

We also give a set of algorithmic typing rules, and prove that it 
is sound and complete with respect to the declarative system. The 
proof requires a number of technical innovations, including proving 
soundness and completeness in a mutually-recursive fashion. 

1. Introduction 

Consider an indexed sum type with a numeric index indicating 
whether the left or the right branch is inhabited, written in Haskell- 
like notation as follows: 

data Sum : Nat -> * where 
Left : A -> Sum 0 

Right : B -> Sum (succ n) 

We can use this definition to write a projection function that always 
gives us an element of A when the index is 0: 

left : Sum 0 —> A 
left (Left a) = a 

This definition omits the clause for the Right branch. The Right 
branch has index succ (n) for some n, and the type annotation tells 


[Copyright notice will appear here once ’preprint’ option is removed.] 


us that left’s argument has an index of 0. Since there exists no 
natural number n such that 0 = succ (n), the Right branch cannot 
occur. Therefore it is safe to omit this case from the pattern match. 

This is an entirely reasonable explanation for programmers, 
but language designers and implementors will have more ques¬ 
tions. First, how can we implement such a type system? Clearly 
we needed some equality reasoning to justify leaving off the Right 
case, which is not trivial in general. Second, designers of functional 
languages are accustomed to the benefits of the Curry-Howard cor¬ 
respondence, and expect to see a logical reading of type systems to 
accompany the operational reading. So what is the logical reading 
of GADTs? 

Since we relied on equality information to eliminate the second 
clause, it seems reasonable to look to logical accounts of equal¬ 
ity. However, one of the ironies of proof theory is that it is pos¬ 
sible to formulate equality in (at least) two different ways. The 
better-known approach is the identity type of Martin-Lof; another 
approach is due to |Schroeder-Heisteij l | 1994| and |Girard| l |1992fr . 

Both approaches introduce equality via reflexivity: 


T b refl : (t = t) 

However, they differ in the elimination rule. The Martin-Lof iden¬ 
tity type eliminates equalities with an equality coercion J. A sim¬ 
plified (non-dependent) version of this rule can be formulated as: 
r b e : (s = t) r b t: A(s) 
r b J(e, t) : Aft) 

Note that this kind of rule does not immediately justify the above 
definition of left: since J is a coercion, to use it we need to match 
the Right case and then show it leads to a contradiction]]] 

The elimination rule of Girard and Schroeder-Heister has a 
rather different flavour. It was originally formulated without proof 
terms, in a sequent calculus style: 

for all 0. if 0 £ csu(s,t) then 0(F) b 0(C) 

r, (s = t) b c 

Here, we write csu(s,t) for a complete set of unifiers of s and t. 
So the rule says that we can eliminate an equality s = t by giving 
a proof of the goal C under each substitution 0 that makes the two 
terms s and t equal. 

There are three important features of the Girard/Schroeder- 
Heister rule, two good and one bad. First, when there are no uni¬ 
fiers, there are no premises: if we assume an inconsistent equation, 
we can immediately conclude the goal. For example, consider elim- 


1 Indeed, the identity type by itself is not enough to write the left function: 
without unive rses, MLTT c annot show that a proof of (0 = 1) leads to a 
contradiction (SmiLh|1988) l 
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mating the equality 0 = 1: 


r,(o = i) b c 

Second, this rule is an invertible left rule in the sequent calculus, 
which is known to correspond to pattern matching ( |Krishnaswami| 
|2009[ . These two features line up nicely with our definition of 
head, where the impossibility of the Left case was indicated by the 
absence of a pattern clause. So it looks like the equalities used by 
GADTs correspond to the Girard/Schroeder-Heister equality, not 
the Martin-Lof identity type. 

Alas, the third feature of this rule prevents us from just giving 
a proof term assignment for first-order logic and calling it a day. It 
is formulated in terms of unification, and it works by treating the 
free variables of the two terms as unification variables. But type 
inference algorithms also use unification, introducing unification 
variables to stand for unknown types. So we need to understand 
how to integrate these two uses of unification, or at least how to 
keep them decently apart, in order to take this logical specification 
and implement type inference for it. 

This problem—formulating indexed types in a logical style, 
while retaining the ability to do type inference for them—is the 
subject of this paper. 

Contributions. The equivalence of GADTs to the combination of 
existential types and equality constraints has long been known 
|et al.|2003) . Our fundamental contribution is to reduce GADTs to 
standard logical ingredients, while retaining the implementability of 
the type system. We accomplish this by formulating a system of in¬ 
dexed types in a bidirectional style (combining type synthesis with 
checking against a known type), which is well-known to combine 
practical implementability with theoretical tidiness. 

• Our language supports implicit higher-rank polymorphism in¬ 
cluding existential types. While algorithms for higher-rank uni¬ 
versal polymorphism are well-known ( [Peyton Jones et al.|2007[ 
|Dunfield and Krishnaswami|2013| >, our approach to supporting 
existential types is novel. 

Our system goes beyond the standard practice of tying exis- 
tentials to datatype declarations < |Laufer and Odersky|| 1994} , 
in favour of a first-class treatment of implicit existential types. 
This approach has historically been thought difficult, because 
the unrestricted combination of universal and existential quan¬ 
tification seems to require mixed-prefix unification (i.e., solv¬ 
ing equations under alternating quantifiers). We use the proof- 
theoretic technique of focusing to give a novel polarized sub- 
typing judgment, which lets us treat alternating quantifiers in a 
way that retains decidability while maintaining other essential 
properties of subtyping, such as stability under substitution and 
transitivity. 

• Our language includes equality types in the style of Girard and 
Schroeder-Heister, but without an explicit introduction form for 
equality. Instead, we treat equalities as property types, in the 
style of intersection or refinement types. This means that we do 
not need to write explicit equality proofs in our syntax, which 
permits us to more closely model the way equalities are used in 
OCaml and Haskell. 

• Our calculus includes nested pattern matching, which fits neatly 
in the bidirectional framework, and allows a formal specifica¬ 
tion of coverage checking with GADTs. 

• Our declarative system tracks whether or not a derivation has a 
principal type. The system includes an unusual “higher-order 
principality” rule, which says that if only a single type can 
be synthesized for a term, then that type is principal. While 


this style of hypothetical reasoning is natural to explain to 
programmers, it is also extremely non-algorithmic. 

• We formulate an algorithmic type system (Section [4]i for our 
declarative calculus, and prove that typechecking is decidable, 
deterministic E3- and sound and complete (Sections[5jj6]> with 
respect to the declarative system. 

Supplementary material. We submitted two supplemental files: 
one with rules that we omitted for space reasons, and another (very 
long) file with detailed proofs and omitted lemma statements. 

2. Overview 

To orient the reader, we give an overview and rationale of the 
novelties in our type system, before getting into the details of 
the typing rules and algorithm. We explain our design choices 
by continuing with the Sum type definition from the introduction. 

kind of declaration can be desugared into type expressions that use 
equality and existential types to express the return type constraints; 
the example in the introduction desugars into something like 

Sum n = (A x (n = 0)) + (3m : N. B x (n = succ(rn))) 
While simple, this encoding suffices to illustrate all of the key 
difficulties in typechecking for GADTs. 

Universal, existentials, and type inference. All practical typed 
functional languages must support some degree of type inference, 
most critically the inference of type arguments. That is, if we have 
a function f of type Va. a -t a, and we want to apply it to the 
argument 3, then we want to write f 3, and not f [Nat] 3 (as would 
be the case in pure System F). Even with a single type argument, 
this is a rather noisy style, and programs using even moderate 
amounts of polymorphism would rapidly become unreadable. 

However, omitting type arguments has significant metatheoret- 
ical implications. In particular, it forces us to include subtyping 
in our typing rules, so that (for instance) the polymorphic type 
Va. a —» a can be viewed as a subtype of its instantiations (like 
Nat -> Nat). 

For the subtype relation induced by polymorphism, subtype en- 
tailment is decidable (under modest restrictions). Matters get more 
complicated when existential types are also included. As can be 
seen in the encoding of the Left constructor of the Sumn type, 
existentials are necessary to encode equality constraints in GADTs. 
But the naive combination of existential and universal types re¬ 
quires doing unification under a mixed prefix of alternating quanti¬ 
fiers jMiller| 1992| , which is undecidable. Thus, programming lan¬ 
guages traditionally have stringently restricted the use of existential 
types. They tie existential introduction and elimination to datatype 
declarations, so that there is always a syntactic marker for when to 
introduce or eliminate existential types. This permits leaving exis¬ 
tentials out of subtyping altogether, at the price of no longer permit¬ 
ting implicit subtyping (such as using Ax. x + 1 at type 3 a. a —> a). 

While this is a practical solution, it increases the distance be¬ 
tween surface languages and their type-theoretic cores. Our goal is 
to give a direct type-theoretic account of the features of our surface 
languages, avoiding complex elaboration passes. 

The key problem in mixed-prefix unification is that the or¬ 
der in which to instantiate quantifiers is unclear. When deciding 
F h Va. A(a) < 3b. B(b), we have the choice to choose an in¬ 
stantiation for a or for b, so that we prove the subtype entailment 
F h A(t) < 3b. B(b) or the subtype entailment V \~ Va. A(a) < 
B(t). An algorithm will introduce a unification variable for a and 
then for b, or the other way around—and this choice matters! In the 
first order, b may depend on a, but not vice versa; with the second 
order, the allowed dependencies are reversed. Accurate dependency 
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tracking amounts to Skolemization, which means we have reduced 
the problem to higher-order unification. 

We adopt an idea from polarized type theory. In the language 
of polarization, universals are a negative type, and existentials are 
a positive type. So we introduce two mutually-recursive subtype 
relations: F h A < + B for positive types and F h A < B 
for negative types. The positive subtype relation only deconstructs 
existentials, and the negative subtype relation only deconstructs 
universals. This fixes the order in which quantifiers are instantiated, 
making the problem decidable (in fact, rather easy). 

The price we pay is that fewer subtype entailments are deriv¬ 
able. But the lost subtype entailments are those that rely on “clever” 
quantifier reversals, and all such entailments can be mimicked by 
writing identity coercions. So we do not lose fundamental expres¬ 
sivity, but we do gain decidability. 

Equality as a property. The constructors in the datatype decla¬ 
ration above contain no explicit equality proofs: we can construct 
a value Left a without giving an equality proof that the index is 
zero. This is the usual convention in Haskell and OCaml, but our 
encoding pairs a value together with a proof. As before, we would 
like to model this feature directly, so that our calculus stays close 
to surface languages, without sacrificing the logical reading of the 
system. 

In this case, the appropriate logical concepts come from the 
theory of intersection types. A typing judgment such as e : A x 
B can be viewed as giving instructions on how to construct a 
value (pair an A with a B). But types can also be viewed as 
properties, where e : X is read “e has property X”. To model 
GADTs accurately, we treat equations t = t' as properties, using 
a property type constructor A A P to model elements of type A 
satisfying the property (equation) P. (We also introduce P D A for 
its adjoint dual.) So our encoding is really: 

Sumn = (A A (n = 0)) + (3m :N.BA(n = succ (m))) 
Then inj 1 a inhabits Sum n only if the property n = 0 is true. 
Handling equality constraints through intersection types means that 
certain restrictions on typing that are useful for decidability, such 
as restricting property introduction to values, arise naturally from 
the semantic point of view—via the value restriction needed for 
types ( |Davies and Pfen-| 


Bidirectionality, pattern matching, and principality. Something 
that is not, by itself, novel in our approach is our decision to formu¬ 
late both the declarative and algorithmic systems in a bidirectional 
style. Bidirectional checking is a popular implementation choice 
(for systems ranging from dependent types ( |Coquand| 1996| |Abel| 
l et al.JI2008l> to OO langu ages like C# and Scala ( [Bierman et ah| 
|2007||0dersky et al.|200 1fr. b ut also has good proof-theoretic foun- 
dations l |Watkins et al.|2004| >, making it useful both for specifying 
and implementing type systems. Bidirectional approaches make it 
clear to programmers where annotations are needed (which is good 
for specification), and can also remove unneeded nondeterminism 
from typing (which is good for both implementation and proving 
its correctness). 

However, it is worth highlighting that because both bidirection¬ 
ality and pattern matching arise from focalization, these two fea¬ 
tures fit together extremely well. In fact, by following the blueprint 
of focalization-based pattern matching, we can give a coverage¬ 
checking algorithm that explains when it is permissible to omit 
clauses in pattern matching (such as the omission of the Right 
case from the left function in the introduction). 

In the propositional case, the type synthesis judgment of a bidi¬ 
rectional type system generates principal types: if a type can be 
inferred for a term, that type is unique. This property is lost once 


Expressions e ::= x | 0 | Ax. e [ ei (e 2 •• s) | (e : A) 

I <ei,e 2 ) | inj 1 e | inj 2 e | case(e,n) 

Values v x | () Ax. e | (v : A) 

I (vi,V2) I inj 1 v | inj 2 v 

Spines s • J e •• s 

Patterns p ;:= x | (pi, p 2 ) I inj, p | inj 2 p 

Branches 7t ::= J =£• e 

Lists of branches n • (n I n) 


Figure 1. Source syntax 


Universal variables a, |3,y 

Sorts k 

Types A, B,C 

Terms/monotypes t, x, a 

Propositions P, Q 

Contexts ¥ 

Polarities ± 

Binary connectives © 

Principalities p, q 


%- * | N 

::= 1|A—>B|A + B|AxB 
| a | Va: k. A | 3a: k. A 
| P Z> A | A A P 
::= zero | succ(t) | 1 | a 
|x—>a|x+ff|xxff 
t = t' 

i-sc ■ |¥,a: k |¥,x: Ap 

«s+|- 

| + I x 

• I / 


Figure 2. Syntax of declarative types and contexts 


quantifiers are introduced into the system, which is why it is not 
much remarked upon. However, prior work on GADTs, starting 
with |Simonet and Pottier| l [2007) , has emphasized the importance of 
the fact that handling equality constraints is much easier when the 
type of a scrutinee is principal. Essentially, this ensures that no ex¬ 
istential variables can appear in equations, which prevents equation 
solving from interfering with unification-based type inference. The 
Outsideln algorithm takes this consequence as a definition, permit¬ 
ting non-principal types just so long as they do not change the val¬ 
ues of equations. However, |Vytiniotis et al. | ( [20 11 ) note that while 
their system is sound, they no longer have a completeness result for 
their type system. 

We use this insight to extend our bidirectional typechecking al¬ 
gorithm to track principality: The judgments we give track whether 
types are principal, and we use this to give a relatively simple speci¬ 
fication for whether or not type annotations are needed. We are able 
to give a very natural spec to programmers—cases on GADTs must 
scrutinize terms with principal types, and an inferred type is princi¬ 
pal just when it is the only type that can be inferred for that term— 
which soundly and completely corresponds to the implementation- 
side constraints: a type is principal when it contains no existential 
unification variables. 

3. Declarative Typing 

3.1 Syntax 

Expression language. Expressions (Figure^ are variables x, the 
unit value 0, functions Ax. e, applications to spines ei (e 2 •• s), 
annotations (e : A), pairs (ei, e 2 ), injections into a sum type inj k e, 
and case expressions case(e,n) where n is a list of branches n, 
which can eliminate pairs and injections; see below. 

Values v are standard (for a call-by-value semantics). 
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checking, eq. elim. subtyping coverage 

¥/PFe4=Cp 'I'l-A^B V F n covers A 


\ 1 


spine typing _ type checking match, eq. elim. 

¥Fs:Ap>Bq ^he^Ap ¥/PHnnA# 


\ f \ / 

principality-recovering / pattern matching 
spine typing / ip h TT :: A <J= C p 

¥hs:Ap>Brql J 

V type synthesis 
¥he=>Bp 


Cp 


Figure 3. Dependency structure of the declarative judgments 


ky l_ ^ -g Under context V, type A is a subtype of B, 

I_ ~ decomposing head connectives of polarity ± 


fh A type nonpos[A) nonneg(A) 



¥ F A <* A 



¥F A < B nonpos{ A) 

nonpos( B) 


¥ F A < + B 



¥F A < + B nonneg( A) 

nonneg(B) ^ 


¥FACB 


¥F 

x : k ¥ F [T/a]A <~ B ^ 

¥, |3 : k F A <~ B 


¥FVo:k.A<~B 

¥ F A < - V|3:k. B 

¥,a 

: k F A < + B ^ ¥Ft:k 

¥ F A < + tr/pjB 

¥F 

3a:K. A < + B “ ¥ F 

A < + 3|3:k. B 


Figure 4. Subtyping in the declarative system 


A spine s is a list of expressions—arguments to a function. 
Allowing empty spines is convenient in the typing rules, but would 
be strange in the source syntax, so (in the grammar of expressions 
e) we require a nonempty spine ei ■■ s. 

Patterns p consist of pattern variables, pairs, and injections. A 
branch 7t is a sequence of patterns p with a branch body e. We 
formulate pattern clauses as sequences as a technical convenience 
to specify pattern typing and coverage checking inductively, by 
letting us deconstruct tuple patterns into a sequence of patterns. 

Types. We write types as A, B and C. We have the unit type 1, 
functions A —> B, sums A + B, and products A X B. 

We have universal and existential types Va : k. A and 3a : k.A; 
these are predicative quantifiers over monotypes (see below). We 
write a, |3, etc. for type variables; these are universal, except when 
bound within an existential type. 

We also have a guarded type P D A, read “P implies A”. This 
implication corresponds to type A, provided P holds. Its dual is 
the asserting type A A P, read “A with P”, which witnesses the 
proposition P. In both types, P has no runtime content. 

Sorts, terms, monotypes, and propositions. Terms and mono¬ 
types t, T, cr share a grammar but are distinguished by their sorts k. 
Natural numbers zero and succ(t) are terms and have sort N. Unit 
1 has the sort * of monotypes. A variable a stands for a term or a 
monotype, depending on the sort k annotating its binder. Functions, 
sums, and products of monotypes are monotypes and have sort *. 
We tend to prefer t for terms and a, T for monotypes. 


A proposition P or Q is simply an equation t = t'. 

Note that terms, which represent runtime-irrelevant informa¬ 
tion, are distinct from expressions; however, an expression may 
include type annotations of the form P D A and A A P, where 
P contains terms. 

Contexts. A declarative context V is an ordered sequence of uni¬ 
versal variable declarations ot : k and expression variable typings 
x : Ap, where p denotes whether the type A is principal (Section 
|3.3j . A variable a can be free in a type A only if a was declared to 
the left: a : *, x : ap is well-formed, but x : ap, a : * is not. 

3.2 Subtyping 

We give our two subtyping relations in Figure [4] We treat the 
universal quantifier as a negative type (since it is a function in 
System F), and the existential as a positive type (since it is a 
pair in System F). We have two typing rules for each of these 
connectives, corresponding to the left and right rules for universals 
and existentials in the sequent calculus. 

We treat all other types as having no polarity. The positive and 
negative subtype judgments are mutually recursive, and the iH 
rule permits switching the polarity of subtyping from positive to 
nega tive when both of the types are non-positive, and conversely for 
|<t| When both t ypes are neither positive nor negative, we require 
them to be equal |<Refl)| 

In logical terms, functions and guarded types are negative; 
sums, products and assertion types are positive. We could poten¬ 
tially operate on these types in the negative and positive subtype re¬ 
lations, respectively. Leaving out (for example) function subtyping 
means that we will have to do some ^-expansions to get programs 
to typecheck; we omit these rules to keep the implementation com¬ 
plexity low. This also serves to illustrate a point of flexibility in 
the design of a bidirectional type system: we are relatively free to 
adjust the subtype relation to taste! 

3.3 Typing judgments 

Principality. Our typing judgments carry principalities: A! means 
that A is principal, and A / means A is not principal. Note that a 
principality is part of a judgment, not part of a type. In the checking 
judgment ¥ F e 4= A p the type A is input; if p = !, we know 
that e is not the result of guessing. For example, the e in (e : A) is 
checked against A !. In the synthesis judgment ¥ F e 4 Ap, the 
type A is output, and p = ! means it is impossible to synthesize 
any other type, as in ¥ F (e : A) =F A !. 

We sometimes omit a principality when it is / (“not principal”). 
We write pCq, read “p at least as principal as q”, for the reflexive 
closure of! C /. 

Spine judgments. The ordinary form of spine judgment, ¥ F 
s : A p C q, says that if arguments s are passed to a 
function of type A, the function returns type C. For a function 
e applied to one argument e\ , we write e e\ as syntactic sugar 
for e (ei ■■ ■) . Supposing ei synthesizes Ai —> A 2 , we apply 
|Decl—>Spine| checking ei against Ai and using |DeclEmptySpine| 
to deriv e VF ■ : A 2 p A 2 p. 

Rule |DeclVSpine| does not decompose e ■■ s but instantiates a V- 
quantifier. Note that, even if the given type Va : k. A is principal 
(p = !), the type [r/a]A in the prem ise is not prin cipal—we could 
choose a different t. In fact, the q in |DeclVSpine| is also always /, 
because no rule deriving the ordinary spine judgment can recover 
principality. 

The recovery spine judgment ¥ F s : A p > C [q], 
how ever, can rest ore principality in situations where the choice of 
T in |DeclVSpine| cannot affect the result type C. If A is principal 
(p = !) but the ordinary spine judgment p roduces a non-princi pal 
C, we can try to recover principality with IDecISpineRecover] Its 
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V b e<(=Ap Under context V, expression e checks against input type A 
e => A p Under context ¥, expression e synthesizes output type A 

Under context ¥, ¥ (t — t] true 

passing spine s to a function of type A synthesizes type C; 
in the [q] form, recover principality in q if possible 

¥ b e =£> A q ¥bA < pol(B) 


¥hs:Ap»Cq 
¥hs:Ap»C |~q] 


¥ b P true | Under context ¥, check P 
DecICheckpropEq 


X : Ap £ ¥ 
¥ b X =4 Ap 


¥ b 0 4* Ip 

¥ b P true 
¥ b e <= A p 
¥ b ebAAPp 


DeclAI 


¥ b e-bBp 

v chk-1 ¥,(t:cbvbAp 
---- D 

¥ b v Va: k. A p 

v chk-l ¥/PbvbA! 


¥ b A type ¥bebA! 

DeclSub -¥ b (e:A)^A!- 

¥ b t : k ¥ b e •• s : [t/oc] A / » C q 


DeclAnnc 


¥bvbPDA! 


DeclDl 


- Decl— 


¥, x : Ap b ebBp 

¥b s 1 A! > C/ ¥ b Ax. e A —> B 

for all C'. 

if¥b s:A!»C'/thenC , = C |c . d ¥bs:Ap»Cq 


¥ b e •• s : 

Va: k. Ap 

» C q 

¥ b P true 

¥ b e s : 

A p » C q d , 

' ¥ b e ! 

s:PD Ap 

»Cq 

¥ b e4Ap 

¥b s: 

A p » C |"q] 


DecIVSpim 

DeclDSpine 


¥bes4Cq 

jr men x. = x. tr r s : /v p ,?> x, q 

-Cm- DecISpineRecover ^ s : A p » C |~q~| DeclS P inePass 


¥ b ■ : Ap > Ap 
¥ b e <4 Aic p ( 

¥ b inj k e <b= Ai + A2 p 


Ap 

¥ b s:Bp»Cq 

DeclEmptySpine ^ e-S : A-) B p » C q Decl^Spin, 

, ¥ b ei Ai p ¥be 2 bA 2 p 

)ecl+l k -777-j—7-7——7 -t - Decl x I 

¥ b (ei, e 2 ) Ai xA 2 p 


lip / p |_ g/^pl Under context ¥, incorporate proposition P 

I ' _|_| and check e against C 


¥bn::AbCp 
¥ b TT covers A 
¥ b case(e,ll) bCp ‘ 


mgu(t7,T) = _L 
¥/(a = T)b ebCp [ 


mgu(a,T)=0 0(¥) b 0(e) -f= 0(C) p 
- ¥/(ff = T)he ^ Cp - DecICheckUmfy 


Figure 5. Declarative typing 


Under context ¥, 


|¥h IT :: A <= C p 

- DecIMatchEmpty 


check branches 11 with patterns of type A and bodies of type C 
:: A <4 C p ¥ b IT :: A <4 C p 


¥ b ■ A b C p 


¥ b 7i I n :: A <4 C 
¥ b p4e::AbCp 


- DecIMatchSeq 


= C V 


¥ b 0,p4> e :: l.AbCi 
-TT::A,X«=Cp 


¥ b pbe::3ct:K.A,AbCp 

¥ b p, p 4- e :: A k , A <4 C p 
¥ b inj k p, p =4 e :: Ai + A 2 ,A«=C 

A not headed by A or 3 ¥,x:A!b p=^e::A<bCp 


¥bx,p=ie::A,AbC 

l^/phn-A^cp 


DecIMatchNeg 


¥ b (• =3> e) • 4 s Cp 

DecIMatchUnit 

Vb pi,p2,pAe::A 1 ,A 2 ,AbCp 

--- DecIMatchx 

¥ b <p 1 ,p 2 >,p^e::A 1 xA 2 ,AbCp 

¥ / P b pbe::A,AbCp „ , A 

n+ k -^- Decl Match A 

¥ b pbe::AAP,AbCp 

A not headed by A or 3 ¥ b p =4 e :: A <4 C p 


- DecIMatchBase 


¥ b p =/> e :: A,A<4Cp 


DecIMatchWild 


Under context ¥, incorporate proposition P while checking branches 11 
with patterns of type A and bodies of type C 

mgu(cT,T) = ± _ ..... mgu(cr, t) = 0 0(¥) b 0(p =4 e) :: 6(A) 

- DecIMatchU 


¥/<r = T 


::AbCp 


¥ / a = t b p4e::AbCp 
Figure 6. Declarative pattern matching 
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| ¥ h IT covers A | Patterns TT co- 
¥h (• =>e,)in'c 

tt -i- n' 'ftn' 


;r the types A in context TP 
- DecICoversEmpty 


>Fhnci 


v 1, A 


- DecICoversl 


¥ b TT covers A, A 
' ¥b TT' covers Ai, A 2 , A p 


n A, TT l II n R ¥ h TT l covers Ai,A ¥ h n R c, 
¥ b n covers A, + A 2 ,A 

0 = mgu(ti, t 2 ) 0(¥) h 0(TT) covers 0(A o ,A) 

--- Dei 

¥ h TT covers Aq A (ti = t 2 ), A 


¥h TTc< 

- DecICovers • 


¥ b TT covers 3a : k. A, A 
m gu(t 1 , t 2 ) = ± 


rs Ap A (ti = t 2 ), A 


Decl CoversEq Bot 


TT TT Expand head pair patterns in TT 


• • «Pi, Pz), P =¥ e) I n (pi , P 2, P =* e) I n' 

TTl || n R Expand head sum patterns in TT into left TTl and right TTr sets 

_ p e (u, J n *i> n L || n R _ 

-i ■ II ■ (p,p=^e) in ^ (_> P =£• e) I TTl II (_,?=► e) I n R 


(p.p=>- e) ITT = 


(inji p, p => e) I n -i* (p> p =/• e) I TTl || TT R 


(inj 2 p, p = 


y Remove head variable 
_I and wildcard patterns from TT 

p e {u,_} n"n' 
(p,p=^e) in ™ (p^e) in' 


T TT l || (p> p =/• e) I TT R 

y Remove head variable, wildcard, 
_I and unit patterns from TT 

p e (u,_, ()} n~n' 

( P ! P =?• e) in (p => e) i n' 


Figure 7. Match coverage 


first premise is ¥ h s : A ! C /; its second premise (really, an 
infinite set of premises) quantifies over all derivations of ¥ h s : 
A ! C' /. If C' = C in all such derivations, then the ordinary 
spine rules erred on the side of cauti on: C is actually prin cipal, so 
we can set q = ! in the conclusion of |DeclSpineRecoverl 

If some C' ^ C, th en C is certainly not principal, and we must 
apply |DeclSpinePassl which simply transitions from the ordinary 

judgment to the recovery judgment. _ 

We need to stop and ask: Is |DeclSpine Reco ver| well-founded? 
If the second premise quantified over the same judgment form as 
the conclusion, certainly not; hence our distinction between the 
ordinary and recovery judgments. But the deri vations in the se cond 
premise may have checking derivations (via |Decl—>Spine| >, and 
in turn synthesis derivations, and in turn (via |Decl— >E^ the sa me 
recovery j udgment! We are saved by the fact that |Decl—>Spine| and 
| Decl ^E| decompose their subject (the spine s or expression e)— 
any deriva tions of a recovery j udgment lurking within the second 
premise of |DeclSpineRecover| must be for a smaller spine. 

Pattern matching. The |DeclCasel rule checks that the scrutinee 
has a principal type, and then invokes the two main judgments for 
pattern matching. The ¥b TT :: A <= C p judgment checks 
that each branch in the list of branches TT is well-typed, and the 
¥ I- TT covers A judgment does coverage checking for the list of 
clauses. Both of these judgments take a vector A of pattern types 
to simplify the specification of coverage checking. 


The ¥ h TT :: A <= C p judgment (in Fi gure|l5| systematic ally 
checks the coverage of each clause inTT: the|PeclMatchEmpty| rule 
succeeds on the empty list, and the |DeclMatchSeq| rule checks one 
clause and recurs on the remaining elements. 

The remaining rules for sums, units, and products break down 
patterns left to right, one constructor at a time. Produ cts also extend 
the pattern and type sequences, with |DeclMatchx| breaking down 
a pattern vector headed by a pair pattern (p,p') ,p into p,p',p 
(also turning the type sequence fr om A x B, C into A, B, C). Once 
all the patterns are eliminated, the |DeclMatchBase| rule says that if 
the body typechecks, then the clause typechecks. For completeness, 
the variable and wildcard rules are both restricted so that any top- 
level existentials and equations are eliminated before discarding the 
type. 

The existenti al elimination rule peel Matchzl | unpacks an exis¬ 
tential type, and |DeclMatchA| breaks apart a conjunction by elim¬ 
inating the equality using unification. The |DeclMatch_L| rule says 
that if the equation is false then the branch always succeeds, be¬ 
cause this case is impossible. The |DeclMatchUnify| rule unifies the 
two terms of an equation and applies the substitution before con¬ 
tinuing to check typing. Together, these two rules implement the 
Schroeder-Heister equality elimination rule. Because our language 
of terms has only simple first-order terms, either unification will 
fail, or there is a most general unifier. 

The ¥ h TT covers A judgment (in Figu rc| 1 6) checks whether a 
set of patterns covers all the possible cases. As with match typing, 
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we systematically deconstruct the sequence of types in the pattern 
clause, but this time, we need a set of auxiliary operations to expand 
the patterns. For example, the FI TT / operation takes every 
branch (p,p'), p =4- e and expands it to p,p', p =4 e. To keep 
the sequence of patterns aligned with the sequence of types, we 
also expand variables and wildcard patterns into two wildcards: 
x, p =4 e beco mes p =4 e. After expanding out all the pairs, 
|DeclCoversx | checks coverage by breaking down the pair type. 

For sum types, we expand a list of branches into two lists, one 
for each injection. So FI TT L || Ff R will send all branches 

headed by inj 1 p into F1 l and all branches headed by inj 2 p into 
FIr, with varia bles and wildcards being sent to both sides. Then 
|DeclCovers+| can check the coverage of the left and right branches 
independently. _ 

As wit h typing, |DeclCovers3| j ust unpacks the existential type, 
Likewise, |DeclCoversEqBot| and |DeclCoversEq| handle the two 
cases arising from equations. If an equation is unsatisfiable, cov¬ 
erage succeeds since there are no possible values of that type. If 
it is satisfiable, we apply the substitution and continue coverage 
checking. 

4. Algorithmic Typing 

Our algorithmic system mimics our declarative rules as closely as 
possible, with one key difference: whenever the declarative system 
would make a guess, we introduce an existential variable into the 
context (written with a hat &). As typechecking proceeds, we refine 
the value of the existential variables to reflect our increasing knowl¬ 
edge. This means that each of the declarative typing judgments has 
a corresponding algorithmic judgment taking both an input and an 
output context: the type checking judgment Fh e <= A p HA 
now takes an input context T and yields an output context A re¬ 
flecting our increased knowledge of what the types have to be. A 
judgment F —» A, explained in Section [4~4| formalizes the notion 
of increasing knowledge. 

These judgments are documented in Figure [13] which has a 
dependency graph of the algorithmic judgments. Each declarative 
judgment has a corresponding algorithmic judgment, but the algo¬ 
rithmic system adds a few more judgments, such as type equiv¬ 
alence checking F F A = B H A and variable instantiation 
F h & := t : k HA. Declaratively, these judgments correspond 
to uses of reflexivity axioms; algorithmically, they correspond to 
the process of solving existential variables to equate terms. 

We give the algorithmic typing rules in Figure [l2| but rules for 
most other judgments are in the supplemental appendix. 


Universal variables a, |3, y 
Existential variables &, |3, i> 


Variables u 

Types A, B,C 

Propositions P, Q 

Binary connectives © 

Terms/monotypes t, t, a 


a a 

s= 11 a I ft 

| Va: k.A| 3a: k. A 
I P D A | A A P 
| A-> B | A + B | A x B 



= zero | succ(t) |l[a|ft 
|t-mt|t+ct|txct 


Contexts F, A, 0 • | F,u : k | T, x: Ap 

r, & : K = T | F, a = t | F, ►u 


Complete contexts fl ::= • | fl, a : k | fl, x : Ap 

| Q, ft : k = t | Q, a = t [ Q, ►u 


Possibly-inconsistent contexts A x ::= A | _L 


Figure 8. Syntax of types, contexts, and other objects in the algo¬ 
rithmic system 

Pll 

.an« 

m- 1 

f [tit when (a = r) e F 

— 1 a otherwise 

[r[ft: K = T ]]ft 

iM OTt 

[F[ft : k]] ft 

= & 

[F](A D B) 

= ([F]A] 3 ( [r] B ) 

tri(AAB) 

« ([F]A)A([r]B) 

[r](A® B) 

» (01 A) © ([FIB) 

[r](Va : k. A) 

m Va : K. [F]A 

[F](3a: k. A) 

= 3a : k. [F]A 


Figure 9. Applying a context, as a substitution, to a type 


An equation a = T must appear to the right of the universal 
variable’s declaration a : k. 

Complete contexts. A complete algorithmic context, denoted by 
fl, is an algorithmic context with no unsolved existential variable 
declarations. 


4.1 Syntax 

Expression language. The expression language is the same as in 
the declarative system. 


Possibly-inconsistent contexts. Assuming an equality can yield 
inconsistency: for example, zero = succ(zero). We write A for 
either a valid algorithmic context A or inconsistency _L. 


Existential variables. The algorithmic system adds existenual 
variables &, (3, to types and terms/monotypes (Figure[8]l. We use 
the same meta-variables, e.g. A, B, C for types. We write u for 
either a universal variable a or an existential variable &. 

Contexts. An algorithmic context T is a sequence that, like a 
declarative context, may contain universal variable declarations 
a : k and expression variable typings x : Ap. However, it may 
also have: 

• unsolved existential variable declarations 6t: k (included in the 
F, u : k production); 

• solved existential variable declarations & : k = t; 

• equations over universal variables a = t; and 

• markers ► u . 


4.2 Context substitution 

An algorithmic context can be viewed as a substitution for its 
solved existential variables. For example, 6t = 1, $ = &—>1 can 
be applied as if it were the substitution l/6t, (6t—>l)/@ (applied 
right to left), or the simultaneous substitution 1 /&, (1—>l)/j§. We 
write [F] A for T applied as a substitution to type A; this operation 
is defined in Figure[9] 

Applying a complete context to a type A (provided it is well- 
formed: Cl h A type) yields a type [fl] A with no existentials. 
Such a type is well-formed under the declarative context obtained 
by dropping all the existential declarations and applying Cl to 
declarations x : A (to yield x : [fl] A). We can think of this context 
as the result of applying Cl to itself: [fl]fl. 

More generally, we can apply fl to any context T that it extends. 
This operation of context application [£1]F is given in Figure [To| 
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[■]• 

[£1, x : Ap](F,x : Arp) 
[O, a : k](T, a : k) 

[a, ► u ](r> u ) 

[Q,a = t](r,a = t / ) 


[fl]F, x : [Q]Ap if [fl]A = [Cl] Ar 

[Q]r, ol : K 

mr 

[[Q]t/a][Q]r if [Q]t = [Q]t' 
f[Q]r'whenr = (r',&:K = t / ) 

< [Q]F' when T = (F', ft : k) 

I [fl]F otherwise 


Figure 10. Applying a complete context C to a context 


The application [fl]F is de fined if and only if F —> C (context 
extension; see Section |4~4| >, and applying C to any such F yields 
the same declarative context [fl]fl. 

Complete contexts are essential for stating and proving sound¬ 
ness and completeness, but are not explicitly distinguished in any 

4.3 Hole notation 

Since we will manipulate contexts not only by appending declara¬ 
tions (as in the declarative system) hut by inserting and replacing 
declarations in the middle, a notation for contexts with a hole is 
useful: T = Fo[0] means F has the form (Fl, 0, Fr). For example, 
if F = r o [0] = (ft, 0,x : 0), then r o [0 = ft] = (ft, 0 = ft,x : 0). 
Since this notation is concise, we use it even in rules that do not 
replace declarations, such as the rules for type well-formedness. 
Occasionally, we also need contexts with two ordered holes: 

T = To[0i] [02] means T has the form (Tl, 0i, Tm, 02, Fr) 

4.4 The context extension relation 

A context F is extended by a context A, written F —> A, if A has 
at least as much information as F, while conforming to the same 
declarative context—that is, [0]F = [fl]A for some fl. 

We can also interpret V —> A as saying that F is entailed by 
A: all positive information derivable from F (say, that existential 
variable ft is in scope) can also be derived from A (which may 
have more information, say, that ft is equal to a particular type). 

The rules deriving the context extension judgment ( Figure [TT| l 
say that the empty context extends the empty context ( |^->ld| >; a 
term variable typing with A' extends one with A if ap plying th e 
extending context A to A and A' yields the same type j— >Var| ; 
universal variable declarations must match ( | — >Uvar) ; equations 
on uni versal variabl es must match ( |—> Eq n[ >; scope markers must 
match ( |— ^Marker) ; and, existential variables may: 

• be unsolved in both contexts ( | — >Unsolvedf , 

• be solved in both contexts, if applying the extending context A 
makes the solutions equal ( |— ^Solved} , 

• get solved by the extending context ( | — >Solve| l, 

• be added by the extending context, either without a solution 
j — >Add| i or with a solution ( |— >AddSolved| >; 


check equation instantiation 

r h ti = t 2 : K H A * rbft-t:KHA 


type checking equality elim. 

> Fbef=ApHA r/s = t: k H A 1 - 


principality-recovering 
spine typing 

rhs:Ap»B[q]HA 


\ 


Figure 13. Dependency structure of the algorithmic judgments 


also holds: while the solution of |3 in fl is different, in the sense 
that fl contains 0 : * = 1 while A contains 0 : * = ft, applying 
fl to the two solutions gives the same thing: applying fl to A’s 
solution of 0 gives [fl]ft = [fl] 3L — 1, while applying fl to fl’s 
own solution for 0 also gives 1, because [fl] 1 = 1. 

Extension is quite rigid, however, in two senses. First, if a 
declaration appears in F, it appears in all extensions of T. Second, 
extension preserves order. For example, if $ is declared after ft 
in F, then 0 will also be declared after ft in every extension of 
F. This holds for every variety of declaration, including equations 
of universal variables. This rigidity aids in enforcing type variable 
scoping and dependencies, which are nontrivial in a setting with 
higher-rank polymorphism. 

This combination of rigidity (in demanding that the order of 
declarations be preserved) with flexibility (in how existential type 
variable solutions are expressed) manages to satisfy scoping and 
dependency relations and give enough room to manoeuvre in the 
algorithm and metatheory. 

4.5 Determinacy 

Our algorithmic judgments have the nice property that, given ap¬ 
propriate inputs, only one set of outputs is derivable. In addition to 
being nice, we use this property in the proof of soundness, for spine 
judgments: 

Theorem 1 (Determinacy of Typing). Given T, e. A, p such that 
F h e:Ap>Ci qi H Ai and Fh e : A p » C2 q2 H A2, it 
is the case that Ci = C2 and qi = q2 and Ai = A2. 


5. Soundness 


Extension allows solutions to change, if information is pre¬ 
served or increased. The extension 


We show that the algorithmic system is sound with respect to the 
declarative system. 


(ft : 0 : * = ft) —> (ft : * = 1, 0 : * = ft) 

directly increases information about ft, and indirectly increases 
information about 0. Perhaps more interestingly, the extension 

(ft : * = 1, 0 : * = ft) —» (ft : * = 1, 0 : * = l) 


5.1 Equating lemmas 

For several auxiliary judgment forms, soundness is a matter of 
showing that, given two algorithmic terms, their declarative ver¬ 
sions are equal. For example, for the instantiation judgment we 
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■> A F is extended by A 


r,x: Ap —> A,x : A'p 
T— i 

->Unsolved - 


r, a : k —i 
[A]t = [A]t' 


r —> A [A]t = [A]t' 


-> A, $ : k' = t 
A 

—-iMarker 


Figure 11. Context extension 


Fhe^ 


rh s 
rh s 


Ap H A Under input context T, expression e checks against input type A, with output context A 
Ap HA Under input context T, expression e synthesizes output type A, with output context A 
Under input context F, 

passing spine s to a function of type A synthesizes type C; 
in the [q] form, recover principality in q if possible 

A q b 0 0 b A < : pol(B) B HA F; A! type F b e <= [f]A ! - 


:Ap » C q HA 
: AP» C fql HA 


(x: Ap) e F , 
Fb x4 [F] A P H r 


Fb eb=Bp b A 


v chk-I 

T b P true b 0 


Fb O^lpHF 
F, a : k b vb Ap HA 
b vbVa: k. A p b A 


r b (e : A) =b> [A]A ! b A 
lift 


= AAPp bA 
v chk-I r, *. P / P H X 


F[&:*]b ()<(=& b F[& : * = 1] 

,0 F, & : k b e •• s : [&/a]A > C q b A 

T b e •• s : Va : k. A p » C q b A VSplne 

[0]Ap bA a| v chk-I r> P /Pb0 ©bvbHAIbA^p.A'^ 
Al fbvbPDA! bA 31 


Tb vbPDA! bT 

I)x:Apb ebBp bA, x:Ap,0 ( F[&i:*, & 2 :*, = 6 


T b P true b 0 0 b e •• s : [0] A p»Cq HA 


: P D A p » C q HA 
->a 2 ],x:a! b e^& 2 H Ap 


ASpine 

&1 , A' 


4 B p - 


r[& : *] b Ax. e < 1 = & b A 


F b s : A ! 
FEV(C) = 


Tb • : A p » A p - 

Fb e^=Akp bA 


Tbe^Apb© 0b s:Ap»Crql bA 
Tb es 4 C q bA 

» C / b A Fb s : A p » C q HA 

I , . „ ((P = /) or (q=l) or (FEV(C) * 0)) „ . „ 

>cm HA S P' neRecover -Fbs:Ap»C[q] HA- SpmePaSS 

* Tbe<=Apb0 0b s: [0]B p>Cq bA 

' Spme - Fb e-s:A—>Bp»Cq bA- >Spme 


F +l k 


F[a, :*,a 2 : 


T b inj k e 4= Ai + A 2 p b A 

i Ltx 2 :*, 

F b ei <= Ai p b 0 0be 2 b [0]A 2 p b A © b e 2 
Tb (ei,e 2 ) -4= Ai x A 2 p b A X ' 

r[a 2 : *,a, : *,a:* = ai->a 2 ] b < 


* = ai +a 2 ] b e ak -\ a 


F[a : *] b inj k e <b a b A ^ 

r[a 2 :*, a^*, a:* = ai xa 2 ] b ei ai b 0 
: <n [©]a 2 b a _ 

F[a: *] b (ei, e 2 ) a b A 

(a, -4 a 2 ) » c b a 

- ftSpine 


F[a : *] b e s : a > C b A 

Fb eb>A! b0 0 b IT :: [0]A <= [0]C p b A A b n covers [A] A 

F b case(e,Fl) <= C p b A CaSe 


Figure 12. Algorithmic typing 
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Lemma (Soundness of Instantiation). 

Xf P I— & :=t:k HA and & ^ FV([T]t) and [F]t = t and 
A —> Cl then [a]& = [D]t. 

We have similar lemmas for term equality (F b ct = t: k H A), 
propositional equivalence (F h P = Q HA) and type equivalence 
(F h A = B H A). 

5.2 Elimination lemmas 

Our eliminating judgments incorporate assumptions into the con¬ 
text T. We show that the algorithmic rules for these judgments just 
append equations over universal variables: 

Lemma (Soundness of Equality Elimination). Xf [F] cr = a and 
[Ht = t and T h a : k and F h t: k and FEV(cr) U FEV(t) = 0, 
then: 

(1) Iff / u = t:K HA 

then A = (F, 0) where 0 = (ai = ti,..., a n = t n ) and 
for all Cl such that F —> Cl and all t' s.t. Q b t' : k' 
we have [Q, 0]t' = [0][O]t' where 0 = mgufa, t). 

(2) If V / a = t: k H_L then no most general unifier exists. 

5.3 Direct lemmas 

The last lemmas for soundness move directly from an algorithmic 
judgment to the corresponding declarative judgment. 

Lemma (Soundness of Checkprop). 

Iff h P true H A and A — > Cl then V h [OjP true. 

Lemma (Soundness of Algorithmic Subtyping). If [F]A = A and 
[r]B = B and F h A type and T h B type and A —> Cl and 
T h A <: ± B H A then [OjA h [D]A < ± [n]B. 

Lemma (Soundness of Match Coverage). 

Iff b FI covers A and T —> Cl and F b A ! types and [F]A = A 
then [Q]T b FT covers A. 

5.4 Soundness of typing 

With lemmas for all the auxiliary judgments in hand, we can move 
on to the main soundness result. It has six mutually-recursive 
parts, one for each of the checking, synthesis, spine, and match 
judgments—including the principality-recovering spine judgment 
and the assumption-adding match judgment. 

Theorem 2 (Soundness of Algorithmic Typing). 

Given A —> O: 

(i) If T I- e <(= A p HA and F b A p type then [O] A b 
[Q]e^[Q]Ap. 

(ii) If r h e =J> A p H A then [OjA b [Oje # [OjA p. 

(hi) If F b s:Ap3>Bq HA and F b A p type then 
[Q]Ah[0]s:[Q]Ap»[Q]Bq, 

(iv) If F b s : A p > B [q] HA and F b A p type then 
[Q]AF [Q]s:[0]Ap»[Q]B [qj.^ 

(v) Iff b fl::A<(=Cp HA and F b A ! types and [F] A = A 
and Th Cp type 

then [OjA I- [Q]F1:: [Q]A <(= [OjC p. 

(vi) Iff / P h FI :: A 4= C p HA and T jr P prop and 
FEV(P) = 0 and [r]P = P 

and T I- A ! types and Th Cp type 

then [OjA / [OjP b [OjFl:: [OjA <(= [OjC p. 

Much of this proof is simply “turning the crank”: applying 
the induction hypothesis to each premise, yielding derivations of 
corresponding declarative judgments (with O applied to every¬ 
thing in sight), and apply ing the corresponding declarative rule; 
for example, in the |Sub| case we finish the proof by applying 


|DeclSub| The|SpineRecover] case is interesting: we do fin ish by ap- 
plying |PeclSpineRecover| but since |DeclSpineRecover| contains a 
premise that quantifies over all declarative derivations of a certain 
form, we must appeal to completeness! Consequently, soundness 
and completeness are really two parts of one theorem. 

These parts are mutually recursive—later, we’ll see that the 
|DedSpineRecover] case of completeness must appeal to soundness 
(to show that the algorithmic type has no free existential variables). 
We cannot induct on the giv en derivation alone, b ecause the deriva¬ 
tions in the “for all” part of |DeclSpineRecover| are not subderiva¬ 
tions. So we need a more involved induction measure that can make 
the leaps between soundness and completeness: lexicographic or¬ 
der with (1) the size of the subject term, (2) the judgment form, 
with ordinary spine judgments considered smaller than recovering 
spine judgments, and (3) the height of the derivation: 

/ ordinary spine judgment \ 

/ e/s/Fl, < , height(£>) \ 

\ recovering spine judgment / 

Proof sketch — |SpineRecover| case. By i.h., [QjF I- jjDjs : 
[OjA ! S> [OJC q. Our goal is to apply |DeclSpineRecover| 
which requires that we show that for all C' such that [OJ0 F 
s : [OjA ! ^> C' /, we have C' = [OjC. Suppose we have such a 
C'. By completeness (Theorem]^}, F h s : [F]A ! )$> C" q H A" 
where A" —> Cl". We alreadynave (as a subderivation) F b s : 
A ! » C / H A, so by determinacy, C" = C and q = / and 
A" s A. With the help of lemmas about context application, we 
can show C' = [0"]C" = [0"]C = [OjC. 

Using completeness—really, using the i.h.—is justified because 
our measure considers a non-principality-restoring judgment to be 
smaller. 

6. Completeness 

We show that the algorithmic system is complete with respect 
to the declarative system. As with soundness, we need to show 
completeness of the auxiliary algorithmic judgments. We omit the 
full statements of these lemmas, but as an example, if [O] Si = [Ojx 
then F h Si := r : k HA, under certain conditions (including that 

Si i FV(t)). 

6.1 Separation 

To show comp leteness, we will ne ed to show that wherever the 
declarative rul e|DeclSpineRecover| is applied, we can apply the al¬ 
gorithmic rule |bpineRecover[ More concretely, the semantic notion 
of principality—that no other type can be given—must entail the 
syntactic notion that a type has no free existential variables. 

The principality-recovering rules are potentially applicable 
when we sta rt with a principal type A ! but produce C /, with 
|DeclVSpme| changing ! to /. T he proof of comple teness (Thm. 
|3} will use the “for all” part of |DeclSpineRecover| which quan¬ 
tifies over all types produced by the spine rules under a given 
declarative context [Q]F. By i.h. we get an algorithmic spine 
judgment Fh s:A'!^>C / / HA. Since A' is principal, 
any unsolved existentials in C' must have been introduced within 
this derivation—they can’t be in T already. Thus, w e might have 
&:*b s :A' !^> 0 / H &:*,$:* where a |peclVSpine| 
subderivation introduced |3, but Si can’t appear in C'. We also 
can’t equate & and 0 in A, which would be morally equivalent 
to C' = Si. Knowing that unsolved existentials in C' are “new” 
and independent from those in T means we can argue that, if there 
were an unsolved existential in C', it would correspond to an un¬ 
forced cho ice in a|DeclVSpine| subderivation, invalidating the “for 
all” part of |DeclSpineRecoverf Formalizing claims like “must have 
been introduced” requires several definitions. 
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Definition 1 (Separation). 

An algorithmic context F is separable into Fl * F R if (I) V = 
(Fl, Fr) and (2) for all (&: k = t) £ Tr it is the case that 
FEV(t) C dom(F R ). 

If F is separable into Fl* F r , then F R is self-contained in the 
sense that all existential variables declared in Fr have solutions 
whose existential variables are themselves declared in Tr. Every 
context F is separable into ■ * T and into F* •. 

Definition 2 (Separation-Preserving Extension). 

The separated context Ft * Fr extends to A L * F R , written 
(Fl*Fr) -*-> (Al*A r ) 

if(r L ,r R ) —> (Al, Ar) anddom(F L ) C dom(A L ) anddom(F R ) C 
dom(AR). 

Separation-preserving extension says that variables from one 
side of * haven’t “jumped” to the other side. Thus, A L may add 
existential variables to Fi , and Ar may add existential variables to 
Tr, but no variable from F L ends up in A R and no variable from 
Tr ends up in Al. It is necessary to write (Fr * Tr) -*-> (Al * Ar) 
rather than (Fl*F r ) —> (A L * Ar), because only includes the 
domain conditions. For example, (6t* $) —> (&, = &)*■, but 0 

has jumped to the left of * in the context (&, |3 = 6c) * •. 

We prove many lemmas about separation, but use only one of 
them in the subsequent development (in the IDedSpineRecover] 
case of typing completeness), and then only the part for spines. It 
says that if we have a spine whose type A mentions only variables 
in r R , then the output context A extends F and preserves separation, 
and the output type C mentions only variables in A r : 

Lemma (Separation—Main). 

If r L *r R hs:Ap»CqHA orF L *r R h s : A p » C fq] HA 

and Tl * Fr h A p type and FEV(A) C dom(FR) 

then A = (A l * Ar) and (F L * Fr) -*+ (A L * Ar) and FEV(C) C 

dom(AR). 

6.2 Completeness of typing 

Theorem 3 (Completeness of Algorithmic Typing). 

Given T —> fl such thatdom(r) = dom(O): 

(i) Iff A p type and [0]F h [0]e <= [£2]A p andp' C p 
then thereexistA andfl' such that A —> fl' anddom(A) = 
dom(G') and II —» fl' 

and T I- e <(= [r]Ap' HA. 

(ii) If F I- Ap type and [£2]F h [fl]e =$■ A p then there 
exist A, fl'. A', and p' C p such that A —> fl' and 
dom(A) = dom(O') and fl —> fl' 

and T I- e =)> A' p' H A and A'= [A]A'and A = [I2']A'. 
(hi) If F h A p type and [0]r h [12] s : [fl]A p > B q and 
P'Ep 

then there exist A, O', B' and q' C q such that A —) O' 
and dom(A) = dom(O') andO —» O' 
and T h s : [F] A p' » B' q' HA and B' = [A]B' and 
B = [0']B'. 

(iv) If T h A p type and [0]T h [0]s : [0]A p » B fq~| and 
p' C p then there exist A, O', B', and q' C q such that 
A —> O' anddom(A) = dom(O') andfl —> O' 

and F I— s : [r]A p'»B' |"q'"| HA and B' = [A]B' and 
B = [0']B'. 

(v) If T H A ! types and F h C p type and [0]F h [0]F1 :: 
[0]A <= [0]Cp andp' C p then there exist A, O', and C 
such that A —> O' anddom(A) = dom(O') andO —> O' 
and T I- n :: [r]A 4= [F]Cp' HA. 

(vi) If T I- A ! types and IIP prop and FEV(P) = 0 and 
F h C p type and [0]r / [0]P h [0]n :: [0]A 4= [Q]C p 


andp' Cp then there exist A, O', and C such that A —> O' 
and dom(A) = dom(O') and O —» O' 
and r / [r]P h n :: [F]A 4= [F]C p' H A. 

Proof sketch — |DeclSpineRecover|ca.ve. By i.h., T H s : [F]A ! 
C'/HA where A — FTF and O —t O' and dom(A) = 
dom(O') an d C = [Q'lC' 

To apply |SpineRecover| we need to show FEV([A]C') = 0. 
Suppose, for a contradiction, that FEV([A]C') f 0. Construct 
a variant of O' called O2 that has a different solution for some 
ot £ FEV([A]C'). By soundness (Thm. [3), [0 2 ]T h [0 2 ]s : 
[0 2 ] A ! [0 2 ]C' /. Using the separationlemma with the trivial 
separation F = (T* •) we get A = (Al*Ar) and (F* •) -$-> 
(Al* A r ) and FEV(C') C dom(A R ). That is, all existentials in 
C' were introduced within the derivation of the (algorithmic) spine 
judgment. Thus, applying 0 2 to things gives the same result as fl, 
except for C', giving 

[0]F h [0]s : [OJA ! > [0 2 ]C' / 

Now instantiate the “for all C 2 ” premise with C 2 = [0 2 ]C', giving 
C = [0 2 ]C'. But we chose 0 2 to have a different solution for 
St £ FEV(C'), so we have C f [ Q 2 1C': Contrad iction. Therefore 
FEV([A]C') = 0, so we can apply |SpineRecover| 

7. Related Work 

A staggering amount of work has been done on GADTs and in¬ 
dexed types, and for space reasons we cannot offer a comprehen¬ 
sive survey of the literature. So we compare more deeply to fewer 
papers, to communicate our understanding of the design space. 

Proof theory and type theory. As described in Section [l] there 
are two logical accounts of equality—the identity type of Martin- 
Lof and the equality type of |Schroeder-Heister (1994) and |Gi-| 
|rard| \1992) . The Girard/Schroeder-Heister equality has a more 
direct connection to pattern matching, which is why we make 
use of it. |Coquand| j 1996) pioneered the study of pattern match¬ 
ing in dependent type theory. One perhaps surprising feature of 
Coquand’s pattern-matching syntax is that it is strictly stronger 
than Martin-Lof’s eliminators. His rules can derive Axiom K 
(uniqueness of identity proofs) as well as the disjointness of con¬ 
structors. Similarly, constructor disjointness is derivable from the 
Girard/Schroeder-Heister equality, because unification fails when 
two distinct constructors are compared. 

In future work, we hope to study the relation between these two 
notions of equality in more depth; richer equational theories (such 
as the theory of commutative rings or the |3r)-theory of the lambda 
calculus) do not have decidable unification, but it seems plausible 
that there are hybrid approaches which might let us retain some 
of the convenience of the G/SH equality rule while retaining the 
decidability of Martin-Lof’s J eliminator. 

Indexed and refinement types. Dependent ML (Xi and Pfenning! 
|1999^ indexed programs with propositional constraints, catching 
bugs in programs that type-check under the standard ML type disci¬ 
pline but fail to maintain additional invariants tracked by the propo¬ 
sitional annotations. DML worked by extracting constraints from 
the program and passing them to a constraint solver, a powerful 
technique th at led to systems suc h as Stardust ( |Dunfield|2007| ) and 
liquid types ( |Rondon et al.|2008f . 

From phantom types to GADTs. |Leijen and Meijer| ( | 1999[ > in¬ 
troduced the term phantom type to describe a technique for pro¬ 
gramming in ML/Haskell where additional type parameters are 
used to constrain when values are well-typed. This idea proved to 
have many applications, ranging from foreign function interfaces 
( |Blume|2001| i to encoding Java-style subtyping l |Fluet and Pucella| 
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12006} . Phantom types allow constructing values with constrained 
types, but do not easily permit learning about type equalities by 
analyzing them, putting applications such as intensional type anal¬ 
ysis {Harper and Morrisett|| 1995} out of reach. Both |Cheney and| 
|Hinze| ( {2003} and |Xi et al.|{2003} proposed treating equalities as 
a first-class concept, giving explicitly-typed calculi for typecheck¬ 
ing equality eliminations. In these systems, no algorithm for type 
inference was given. 

|Simonet and Pottier] < {2007} gave a constraint-based algorithm 
for type inference for GADTs. It is this work which first identi¬ 
fied the potential intractibility of type inference arising from the 
interaction of hypothetical constraints and unification variables. To 
resolve this issue they introduce the notion of tractable constraints 
(i.e., constraints where hypothetical equations never contain exis- 
tentials), and require placing enough annotations that all constraints 
are tractable. In general, this could require annotations on case ex¬ 
pressions, so subsequent work focused on relaxing this require¬ 
ment. Though quite different in technical detail, stratified infer- 
ence {Pottier and Regis-Gianas||2006} and wobbly types ( |Peyton| 
|Jones et al.|2006} both work by pushing type information from an¬ 
notations to case expressions, with stratified type inference literally 
moving annotations around, and wobbly types tracking which parts 
of a type have no unification variables. Modem GHC uses the Out- 
sideln algorithm {Vytiniotis et al.|20TT} , which further relaxes the 
constraint: as long as case analysis cannot modify what is known 
about an equation, the case analysis is permitted. 

In our type system, the checking judgment of the bidirectional 
algorithm serves to propagate annotations, and our requirement 
that the scmtinee of a case expression be principal ensures that 
no equations contain unification variables. This is close in effect 
to stratified types, and is less expressive than Outsideln. This is 
a deliberate design choice to keep the declarative specification 
simple, rather than an inherent limit of our approach. 

To give a specification for the Outsideln approach, the case 
rule in our declarative system would be permitted to scrutinize an 
expression if all types that can be synthesized for it have exactly 
the same equations, even if they differ in their monotype parts. We 
feared that such a spec would be much harder for programmers to 
develop an intuition for than simply saying that a scmtinee must 
synthesize a unique type. However, the tech nique we use—highe r- 
order rules with implicational premises like |DeclSpineRecover] — 
should work for t his case. _ 

More recently, fGarrigue and Remy| ( |2013} proposed ambivalent 
types, which are a way of deciding when it is safe to generalize 
the type of a function using GADTs. This idea is orthogonal to 
our calculus, simply because we do no generalization at all: ev- 
ery polymorphic function takes an annotation. However, |Garrigue| 
land Remy| ( |2013} also emphasize the importance of monotonicity, 
which says that substitution should be stable under subtyping, that 
is, giving a more general type should not cause subtyping to fail. 
This condition is satisfied by our bidirectional system. 
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Supplemental material for “Sound and Complete Bidirectional Typechecking for Higher-Rank 
Polymorphism and Indexed Types”: 

Complete Rules 

This file contains rules omitted in the main paper for space reasons. 

Lemmas and proofs are in another, much longer, file. 

We also list all the judgment forms: 


Judgment 


Description 


Location 


¥b t: k 

V h P prop 
¥ h A type 
¥ b A types 
Wctx 

'fl-A^B 

V b P true 

V b ebAp 

V b e=jAp 
Vb s : A p » Cq 
¥b s:Ap»Crql 
¥bn::AbCp 
V/Pb II:: A 4= C p 
¥bn covers A 

Tb t: k 
F b P prop 
P b A type 
Tctx 
[P1A 

P b P true H A 
r/PHA 1 
Pb # = t: k HA 
s#t 

r / s a t: k H A x 
Pb A<: ± B H A 
T / Pb A<: B HA 
PbPsQHA 
PbAsBHA 
Pb k H A 

e chk-I 

Pb e<bAp HA 
Pb eHAp HA 
Pb s : A p » C q HA 
Pb s:Ap>C [qj HA 

Pb n::A<=Cp HA 
P/Pbn::AbCpHA 
P b TT covers A 
P—> A 

lojr 


Index term/monotype is well-formed 

Figure 14 

Proposition is well-formed 


Type is well-formed 


Type vector is well-formed 

Figure 14 

Declarative context is well-formed 

Figure 14 

Declarative subtyping 

Figure 4 


Declarative truth 

Figure 5 


Declarative checking 



Declarative synthesis 

Figure 5 


Declarative spine typing 

Figure 5 


Declarative spine typing, recovering principality 

Figure 5 


Declarative pattern matching 

Figure 15 

Declarative proposition assumption 

Figure 15 

Declarative match coverage 

Figure 16 

Index term/monotype is well-formed 

Figure i/ 

Proposition is well-formed 

Figure i/ 

Polytype is well-formed 


Algorithmic context is well-formed 

Figure i / 

Applying a context, as a substitution, to a type 

Figure y| 

Check proposition 

Figure 1 


Assume proposition 

Figure 18 

Check equation 

Figure 19 

Head constructors clash 

Figure 20 

Assume/eliminate equation 

Figure 21 

Algorithmic subtyping 

Figure 22 

Assume/eliminate proposition 

Figure 22 

Equivalence of propositions 

Figure 22 

Equivalence of types 


Instantiate 

Figure 23 

Checking intro form 

Figure 24 

Algorithmic checking 

Figure 12 

Algorithmic synthesis 


Algorithmic spine typing 

Figure 12 

Algorithmic spine typing, recovering principality 

Figure 12 

Algorithmic pattern matching 

Figure 25 

Algorithmic pattern matching (assumption) 

Figure 25 

Algorithmic match coverage 

Figure 26 

Context extension 

Figure 11 

Apply complete context 

Figure 1U 


















































| W h t : K | Under context W, term t has sc 
(a :K )e¥ 


1 :* 

- ZeroSort 


| W h P prop | Under context Y, proposition P is well-formed 

¥bt:N W\- t' :N 


| W h A type | Under context W, type A is well-formed 
(a:*) €V ^ ni 


VI- a type V h 1 type 

VI- A type VI- B type ©€{—>, x,+} 


V, a : k h A type 
V h (Va: k. A) type 
V h P prop V h A type 


V h A © B type 

DeclAIIWF 


- DeclExistsWF 


VI- (3a : k. A) type 
V h P prop V h A type r 
V h A A P type C 


1“ A types Under context V, types in A are well-formed 


for all A e A. 
V h A type 


| V ctx | Declarative context V is well-formed 
Veto x 

- EmptyDecICtx - 


i dom (V) V h A type V ctx a £ dom (V) 

——-— -- HypDecICtx -—--- VarDecICtx 


Figure 14. Sorting; well-formedness of propositions, types, and contexts in the declarative system 
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\w\- TT:: A <(= Cp 


Under context ¥, 


fl- • :: A «= C i 


check branches TT with patterns of type A and bodies of type C 
|Decl Match Empty] ^ h 71 - A <1= C p Y b n :: A <J= C p 


¥ b n I n :: A «= C 
Yb p e :: A <= C p 


— |DeclMatch5eq| 


= Cp 


W\- (),p=^ e:: 1,A<J= C 
- TT :: A, A <t= C 


'I'l- p => e :: 3a : k. A, A <t= C p 
Yb p,p=>e::A k ,A^C 


V b inj k p, p =^> e :: Ai + A2, A i= C 

A not headed by A or 3 H^xiAlb p4e::At=Cp| 
>Fht,p’4e::A,At=C 

|V/PI- IT :: A 4= C p 


|DeclMatch3| 

[DecIMatch+^l 


V b |«4e)n-#C 

|DeclMatchllnit| 

Vb pi,p 2 ,p=^ e:: Ai,A 2 ,A<t= Cp 


- |DeclMatchBase| 


Vb <Pi,p 2 >,?=>e::A 1 xA 2 ,A^C 
V/Pb p=£>e::A, A<t=Cp 


|DeclMatchx| 


|DeclMatchA| 


|DeclMatchNeg| 


A not headed by A or 3 ¥b f 


V b _,?=*. e :: A,A<b= Cp 


— |DeclMatchWild| 


Under context ¥, incorporate proposition P while checking branches TT 
with patterns of type A and bodies of type C 

mgufcr, t) = -L | | mgu(cr, t) = 0 0(V) b 0(p => e) :: 0(A) 

- DecIMatchU - 


V/ff 


e :: A <t= C p 


W / cr = Tb p 


e :: A <t= C p 


— |DeclMatchUnify] 


Figure 15. Declarative pattern matching 


| ^ l~ TT covers A | Patterns TT cover the types A in context V 

— |DeclCoversEmpty| 

— |DeclCoversl] 


TT ™ TT' Wb TT' covers A 


Wb (• =$■ ei) I TT' covers ■ ' 

n-in' ¥b n'< 


¥ b n covers 1, A 
TT -i* n L II TT r fb n L covers A,, A V b n R 
¥ b TT covers A\ + A 2 , A 
0 = mgu(ti,t 2 ) 00k) b 0(TT) covers 0(Ao,A) 


¥ b TT covers A, A 

TT -4 TT' Tb TT' covers A U A 2 ,A 
¥ b TT covers Ai X A 2 , A 


|DeclCoversVar| 


|DeclCoversx| 


— |DeclCovers+| 


¥ b TT covers Ap A (ti = t 2 ), A 


|DeclCoversEq| 


¥ b TT covers 3a : k. A, A 
mgu(ti,t 2 ) = L 


[beclCovers3| 
|DeclCoversEqBot| 


TT TT Expand head pair patterns in TT 


nin' 


«Pi, P 2 ) > P =/■ e) I TT (pi, p 2 , p =$■ e) I TT' 


| TT ^ TTl || TTr Expand head sum patterns in TT into left TTl and right TTr sets 
_ p c {u,_} tt -i* n L || n R _ 

•*&'*(* (p> P e) I TT (_,p^e)in L || (_,p=^e)in R 

TT TT l || n R 


'Fbn covers A 0 A f*j = t 2 ), A 

p c (z,_} n n' 

(p,p=^e) in (_,_,?=> e) in' 

_n n L ||n R _ 

(injl p, P e) I n -&■ (p, p => e) 1 n L || n R 


(inj 2 p, p => e) I n — n L II (p, p =>■ e) 1 n R 


pp var yy/ Remove head variable 
I_| and wildcard patterns from TT 

_ p e(u,J n ^ n' 

• « • (p,p=>e)m « (p^e)in' 


pp ^ pp/ Remove head variable, wildcard, 
I_| and unit patterns from TT 

_ p e (u,_, 0 } n~n' 

• • (p,p^e)m « (p^e)in' 


Figure 16. Match coverage 
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r h T : K Under context F, ti 


- SolvedVarSort 


r I- Ti ® T 2 : 

- SuccSort 


| F h P prop | Under context F, proposition P is well-formed 

F h t: N FU t' : N 


F h t = t 'prop 


| T h A type | Under context T, type A is well-formed 

(u : *) £ F (ft :, 

--- VarWF . 

Thu type F h & type 

T h A type F h B type ® € {—>, x, +} 
T h A ® B type 


- SolvedVarWF 


F : 1 type 
f, a: k h A type 


fl- PdA type 


| F h A p type | Under context F, type A is well-formed and respects principality p 

T h A type FEV([F]A) =0 V h A type 

-F h A ! type - P-cipalWF r h Kg type " 

P h A [p | types Under context T, types in A are well-formed [with principality p] 


for all A £ A. 
T h A type 
T h A types 


TypevecWF 


| T CtX | Algorithmic context F is well-formed 


x<£ dom(F) 

Tctx ThA type 

r, x : A / ctx yP ° 

dom(r) 

^ —— VarCtx 

icer (<x = -)gr rht 

T, a = t ctx 


for all A £ A. 

F h A p type 

- = _ RpncipalTypevecWF 

T h A p types 


x £ dom(r) 

Tctx I'- A type FEV(T;A) = 0 _ 
r,x: Al ctx h 

Tctx & ^ dom(r) rht:K 
- r& . K ^ tcft - SolvedCtx 

< c w r ctx ►u ^ r t „ 


Figure 17. Well-formedness of types and contexts in the algorithmic system 
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| F h P true H A Under context T, check P, with output context A 

F h ti A t 2 : N H A 
T h t, = t 2 true HA ^ 


| r / T 3 —I A -1 Incorporate hypothesis P into F, producing A or inconsistency i 
F / ti A t 2 : N H A x 


Figure 18. Checking and assuming propositions 


| F h ti = t2 : K H A | Check that ti equals t 2 , taking F to A 
- CheckeqVar 


Fh ui-u 


< h r 


r ! Ti A T ; : 


Fh 1 A 1 :* Hr 
© h [0 ]t 2 A [0]t 2 : * H A 


r h zero A zero : N H F CheckeqZer ° 
r[& : k] h & := t : k H A & £ FV(t) 


f h Ti 0 t 2 A x \ © t 2 : * H A 

F h tr A t 2 : N H A 


F P succ(ti) A su cc(t 2 ) :NHA 


r[a : k] h t A St: k H A 


— |CheckeqlnstR| 


Figure 19. Checking equations 


ti # \x ti and t 2 have incompatible head constructors 


zero # succ(t) succ(t) # zero 1 # Ti © t 2 Ti © t 2 # 1 

Figure 20. Head constructor clash 

| F / CT = T : K H A 1 | Unify a and T, taking T to A, or to inconsistency A 

- ElimeqUvarRefl 

F / cr A x : N H A 1 


O'] *1 Ti # ct 2 ffi 2 t 2 


F/aAaiK HF 


F / zero A zero : N H T 
x^FV(t) (a=-)^F c 


T / succ(a) A succ(t) :N HA 


F/aAx:KHF,a = 


- ElimeqUvarL 


a i- FV(t) (a=-) ^ r - t/a «£FV(t)^ - 

r x — tx : i: H T, tx — t F^ e 9 UvarR l r / tx — t : i; HA l Ellme q UvarIT ] 


|ElimeqUvarRA| 


t^a a 6 FV(t) 

F/tA «: k HA 

F / Ti A x( : * H 0 0 / [0]t 2 A [0]t 2 : * H A -1 

F / Ti © t 2 A ti' © %2 : * H A x 
F / t, At,' :* HA 


r / Ti © t 2 a t{ © t 2 : * H A 

CT#T 

r / rr -g- a- ■ ^ -1 I FlimeqClash 


Figure 21. Eliminating equations 
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Fh A < : ± B HA Under input context F, type A is a subtype of B, with output context A 


A not headed by V/S 

B not headed by V/3 F h A = B H A 
rh A<: ± B HA < 

B not headed by V 

r, ►&, & : Kh [6i/0i]A<r B a A,* a ,0 r,P:K 


rhVa:K.A<rB HA 

r, a : Kh A<: + B H A, a : k, 0 _ 
rh 3a: k. A<: + B HA 

neg{ A) 

fh A <: B HA nonpos[ B) 


F h A <: _ V|3 : k. B HA 
A not headed by 3 

r,»p,g:Kh A <: + [$/p]B HA,» p ,0 < 

F h A <: + 3|3 : k. B HA < 

nonpos( A) 

fh Ac - B HA neg{ B) 


pos{ A) 

Th A<: + B HA nonneg{B) 
rhA<hBHA < 

_ Under input context F, 

T h P = Q HA check that P is equivalent to Q 
with output context A 


nonnegl A) 

Th A<: + B HA pos{ B) 

rh A <: B H A < 


r h ti * t 2 : Pi H 0 0 h [0]t| & [0]t 2 : N H A _ 


Th (t, =t 1 ') = (t 2 =t^ HA 


Under input context F, 


F h A = B H A check that A is equivalent to B 
with output context A 


Th nsuHF" 


rhct^&HF - rhlsHF" 

rh AisBi H0 0h [0]A 2 a [0]B 2 H A _ 


r h Ai ® A 2 5 Bi 0 b 2 ha 
r,a: Kh A = B H A, a : k,A' _ w T, a 

rh (Va: k.A) se (Va: k.B) HA 
ThPsQH0 0h [0]A ee [0]B H A 
r h (P Z> A) = (Q D B) HA 

a t fv(t) r[&] h a := - 
r[a] h a = x h a 


- =lnstantiateL 


F a : k h A = B H A, a : k, A* 

Fh (3a: k.A) = (3a: k.B) HA s3 
rhPsQH© 0h [0]A = [0]B H A 
rh (A AP) = (B A Q) HA 

* i. fv(t) rtai h a : = i 
rta] h t = a h a 


|=lnstantiateR| 


Figure 22. Algorithmic equivalence and subtyping 


1 Under input context F, 

J instantiate & such that a = t with output context A 


^ £ unsolved (T[a : k][$ : 


r 0 ,a:K,n r a^TiK Hr 0 ,a:K = T,n na : k][0:k] h a : =g: K h na : k]$ : K = a] 

r[a 2 : a, : a : * = ai ® a 2 ] h a! ^ t, : * h 0 0 h a 2 ?= [ 0 ]t 2 : * h a 


r;a:NH 




T[a : *] h a := Ti 0 t 2 : * HA 

na,: n, a: n = succca,)] h a, ?= 


(ti) : N H A lnStSuCC 


Figure 23. Instantiation 
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checked introduction form 


e chk-I Expression e is a 


Ax. e chk-I () chk-I (ei, e 2 ) chk-I inj k e chk-I 


Figure 24. “Checking intro form” 


rbrT::A<=CpHA 


Under context T, 

check branches TT with patterns of type A and bodies of type C 

Tb 7r::A<=Cp H 0 0b n' ::Af=CpHA 


Tb -::Af=Cp HP 

TbebCpHA 

——7-r-—-—- MatchBast 

r b (■ e) :: • 4= C p b A 
f, oc: k b p::A,AbCp HA,«:k, 0 
T b p =1> e :: (3a : k. A), A bCp HA 
T b pi, p 2 , p =» e :: Ai, A 2 , A 4= C p HA ^ 

f b (pi, p 2 ), p e :: Ai x A 2 , Af=Cp HA 


Fb7t|TT'::A4=CpHA 

F b p^e::Af=Cp HA 

- = -— Matchllnit 

Fb (),p4e::l,A<b Cp HA 

F/Pb p=>e:: A,Af=Cp HA 
Fb pHe::AAP,Af=Cp HA 
r b p, p =4 e :: A k , A<bCp HA ^ 

F b (inj k p), p =4- e :: Ai + A 2 , A bCp HA 


A not headed by A or 3 T, z:A!b pH>e ::Af=Cp HA, z : A!, A 
-=- l\ 

Fb z, p e :: A, AbCp HA 

A not headed by A or 3 Tb pHe::A-bCp HA 

- -^---- UptchWild 

Fb p e :: A, A 4= CpHA 


| T / Ph TT :: A <j= C p HA 
r/a=r-.K H L 


Under context F, incorporate proposition P while checking branches FI 
with patterns of type A and bodies of type C 

r,.p/aA X : K H0 0bp4e::AbCp 


r/cr = Tb p4e::Af=Cp HF 


F/ ff = Tb p = 


= C p H A 


Figure 25. Algorithmic pattern matching 


| F h Ff covers A Under context T, patterns TT cover the types A 

F b TT / covers A 


=> ei) I TT covers ■ 

Ff' T b TT' covers Ai, A 2 , A 
Fb TT covers Ai x A 2 ,A 

F, a : k b TT covers A 

-Cover; 

F b TT covers 3a : k. A, A 


5 TT' 

T b TT covers A, A 
TT TT l || n R 

F / [r]ti A [P]t 2 : k H A 


rb n L c 
rb ncc 


TT TT' F b TT' covers A 
-=- C 

T b TT covers 1, A 

ers Ai, A F b TTr covers A 2 , A 
-=- Cc 

TO At + A 2 ,A 

- [A]TT covers [A]Ao, [A] A 


F b TT covers Ao A (ti = t 2 ), A 
F / mt, = [F]t 2 :k Hi 


T b TT covers Ao A (ti = t 2 ), A 


Figure 26. Algorithmic match coverage 
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